The new script's condition is only ctx.crowdstrike?.LogonType instanceof String && ctx.crowdstrike.LogonType != '', which is not scoped to process events. LogonType is present on Windows authentication events, so this stamps process.interactive onto documents that have no process. This is observable in the regenerated fixtures: in test-fdr.log-expected.json a UserLogoff event (event.category: ["authentication"]) now gains a lone process: { "interactive": false } object, and test-user-map / test-windows show the same on non-process events. The effect is also broader than the changelog entry ("Map CommandHistory events to ECS process fields") describes. Attaching a process attribute to an authentication event is semantically misleading and creates a process object where none belongs.

LogonType is an attribute of the Windows logon session, but ECS defines process.interactive per-process ("inferred from the processes file descriptors... the character device for the controlling tty is the same as stdin and stderr") — the definition this PR adds to docs/README.md line 3197. Applying the session's LogonType to whatever process object happens to be on the event produces wrong values, and the PR's own fixtures show it:

• packages/crowdstrike/data_stream/fdr/_dev/test/pipeline/test-windows.log-expected.json line 11952 now asserts "interactive": true for the Windows System process (event_simpleName LogonBehaviorCompositionDetectInfo, ImageFileName/CommandLine "System", entity_id 21475403566). System is the kernel process; it has no controlling tty and can never be attached to an interactive shell. It is marked interactive purely because the session's LogonType is 2.
• test-fdr.log-expected.json lines 8069, 8557, 9370 and test-windows.log-expected.json lines 8756, 8963, 9153 add "interactive": false to UserLogon/authentication events whose process object is only a ContextProcessId reference (entity_id plus thread.id). ECS false means "known to be non-interactive"; here interactivity is simply unknown, so the pipeline is asserting a fact the source event does not carry.

The ctx.process != null gate added in this revision keeps the field off events with no process object at all, but it does not distinguish the process the logon session actually belongs to from an unrelated context/target process reference, so both cases above still fire.

For the two-command fixture in test-fdr-command-history.log, process.command_line becomes "sc stop CSFalconService" and the second command, "Stop-Service -Name CSFalconService -Force", never reaches process.command_line (test-fdr-command-history.log-expected.json line 102). Detection rules and searches on process.command_line therefore see only one of the N commands, chosen by position.

Index 0 is not a defensible choice: the same event carries FirstCommand, LastAdded, LastDisplayed, CommandSequence and CommandCount precisely because the history is an indexed rolling buffer, so element 0 is not reliably the newest, the oldest, or the command of interest. The previous revision assigned the whole delimited string; this revision narrowed it to element 0, which trades one wrong value for another.

ECS defines process.command_line as "Full command line that started the process". The process on these events is identified by TargetProcessId (process.entity_id 7292754410393 in the fixture) — the shell — and its own command line is none of the history entries. A related symptom: this script is placed at line 1054, after split_command_line_c3beef26 (line 972), so unlike every other source of process.command_line in this pipeline the value produces no process.args/process.args_count; the fixture's process object has command_line but no args.

The full parsed history is already preserved at crowdstrike.CommandHistory, so nothing is lost by not guessing.

CommandSequence carries the position of the entry within the CrowdStrike command-history buffer ("1" in both events of test-fdr-command-history.log). match_only_text is a text type: it is not doc_values-backed, so the field cannot be used in a terms aggregation, cannot be sorted on, and cannot be matched with an exact term query — all of which are the natural uses of a sequence index when reconstructing command order.

The adjacent CommandCount and CommandCountMax entries (fields.yml lines 221-226) are also match_only_text, but each sits above a commented-out type: long declaration, which marks them as a known legacy compromise rather than the convention to follow for a newly added field.

ECS defines process.command_line as the full command line that started the process identified by process.entity_id. On a CommandHistory event process.entity_id is TargetProcessId (the shell), and crowdstrike.CommandHistory is the buffer of commands typed inside that shell, not the command line that launched it. Assigning the array puts N unrelated command strings into a single-valued ECS field.

This is visible in the committed fixtures: test-fdr-command-history.log-expected.json now carries process.command_line as a two-element array, and test-windows.log-expected.json turns a previously scalar value into a one-element array, while every other event in the same expected file (for example the LogonBehaviorCompositionDetectInfo document with "command_line": "System") keeps a scalar string. The field is therefore scalar on most documents and multi-valued on CommandHistory documents. In ES|QL most functions and aggregations return null and emit a warning on multi-valued rows, so queries and rules over process.command_line behave differently for these documents. The events also get process.command_line without the matching process.args / process.args_count that split_command_line produces for every other command line.

This also moves away from the direction already agreed on this PR (populate process.command_line only when the history holds a single command); the previous revision's data-loss problem is better solved by leaving the field unset for multi-command buffers than by making it an array.

The description now claims the processor is "Placed after split_command_line so that processor only runs on string-valued command lines from crowdstrike.CommandLine." That is not what the ordering does: split_command_line reads process.command_line (populated from crowdstrike.CommandLine), and it is the ctx.crowdstrike?.CommandHistory instanceof String condition, not the position, that keeps this processor off already-converted array values. The sentence is also grammatically broken.

The previous revision recorded that U+00B6 PILCROW SIGN is not formally documented by CrowdStrike but is consistently observed as the delimiter in FDR CommandHistory events. That is the non-obvious reason a magic character appears in the source, and it is the one piece of context a future maintainer cannot recover from the code; the rewrite removed it.

Both new script processors (script_command_history_to_process_command_line_8c3e1f92 here, and script_process_interactive_logon_type_9b3d6c7a further down) attach an on_failure append that omits the tag field and writes a custom string carrying only _ingest.on_failure_message.

Every other on_failure handler in this pipeline uses a tagged append with the full template that also records the failing processor type, tag and pipeline, for example append_error_message_4ef54c75 on the json processor. Without those fields an error.message from these handlers cannot be traced back to the processor that produced it, and the untagged processors will be flagged by elastic-package check once the package moves to format_version 3.6.0 or later.